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Abstract 


Abstraction and Control of TE Networks (ACTIN) refers to the set of 
virtual network (VN) operations needed to orchestrate, control, and 
manage large-scale multidomain TE networks so as to facilitate 
network programmability, automation, efficient resource sharing, and 
end-to-end virtual service-aware connectivity and network function 
virtualization services. 


The Path Computation Element (PCE) is a component, application, or 
network node that is capable of computing a network path or route 
based on a network graph and applying computational constraints. The 
PCE serves requests from Path Computation Clients (PCCs) that 
communicate with it over a local API or using the Path Computation 
Element Communication Protocol (PCEP). 


This document examines the applicability of PCE to the ACTN 
framework. 


Status of This Memo 


This document is not an Internet Standards Track specification; it is 
published for informational purposes. 


This document is a product of the Internet Engineering Task Force 


(IETF). It represents the consensus of the IETF community. It has 
received public review and has been approved for publication by the 
Internet Engineering Steering Group (IESG). Not all documents 


approved by the IESG are candidates for any level of Internet 
Standard; see Section 2 of RFC 7841. 


Information about the current status of this document, any errata, 


and how to provide feedback on it may be obtained at 
https://www.rfc-editor.org/info/rfc8637. 
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Abstraction and Control of TE Networks (ACTN) [RFC8453] refers to the 
of virtual network (VN) operations needed to orchestrate, 


set 


control, 


and manage large-scale multidomain TE networks so as to 


facilitate network programmability, automation, efficient resource 
sharing, and end-to-end virtual service-aware connectivity and 
network function virtualization services. 
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2. 


2. 


The Path Computation Element (PCE) [RFC4655] is a component, 
application, or network node that is capable of computing a network 
path or route based on a network graph and applying computational 
constraints. The PCE serves requests from Path Computation Clients 
(PCCs) that communicate with it over a local API or using the Path 
Computation Element Communication Protocol (PCEP). 


This document examines the PCE and ACTN architecture and describes 
how PCE architecture is applicable to ACTN. It also lists the PCEP 
extensions that are needed to use PCEP as an ACTIN interface. This 
document also identifies any gaps in PCEP that exist at the time of 
publication of this document. 


Further, ACTN, stateful Hierarchical PCE (H-PCE) [PCE-HPCE], and PCE 
as a central controller (PCECC) [RFC8283] are based on the same basic 
hierarchy framework and are thus compatible with each other. 


Background Information 
1. Path Computation Element (PCE) 

The Path Computation Element Communication Protocol (PCEP) [RFC5440] 
provides mechanisms for Path Computation Clients (PCCs) to request a 


Path Computation Element (PCE) [RFC4655] to perform path 
computations. 


The ability to compute shortest constrained TE LSPs in Multiprotocol 
Label Switching (MPLS) and Generalized MPLS (GMPLS) networks across 
multiple domains has been identified as a key motivation for PCE 
development. 


A stateful PCE [RFC8231] is capable of considering, for the purposes 
of path computation, not only the network state in terms of links and 
nodes (referred to as the Traffic Engineering Database or TED), but 
also the status of active services (previously computed paths), and 
currently reserved resources, stored in the Label Switched Paths 
Database (LSP-DB). 


[RFC8051] describes general considerations for a stateful PCE 
deployment and examines its applicability and benefits as well as its 
challenges and limitations through a number of use cases. 


[RFC8231] describes a set of extensions to PCEP to provide stateful 
control. A stateful PCE has access to not only the information 
carried by the network’s Interior Gateway Protocol (IGP), but also 
the set of active paths and their reserved resources for its 
computations. The additional state allows the PCE to compute 
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2. 


be 
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constrained paths while considering individual LSPs and their 
interactions. [RFC8281] describes the setup, maintenance, and 
teardown of PCE-initiated LSPs under the stateful PCE model. 


[RFC8231] also describes the active stateful PCE. The active PCE 
functionality allows a PCE to reroute an existing LSP or make changes 
to the attributes of an existing LSP, or a PCC to delegate control of 
specific LSPs to a new PCE. 


1. Role of PCE in SDN 


Software-Defined Networking (SDN) [RFC7149] refers to a separation 
between the control elements and the forwarding components so that 
software running in a centralized system, called a controller, can 
act to program the devices in the network to behave in specific ways. 
A required element in an SDN architecture is a component that plans 
how the network resources will be used and how the devices will be 
programmed. It is possible to view this component as performing 
specific computations to place flows within the network given 
knowledge of the availability of network resources, how other 
forwarding devices are programmed, and the way that other flows are 
routed. It is concluded in [RFC7399] that this is the same function 
that a PCE might offer in a network operated using a dynamic control 
plane. This is the function and purpose of a PCE, and the way that a 
PCE integrates into a wider network control system including SDN is 
presented in Application-Based Network Operation (ABNO) [RFC7491]. 


-2. PCE in Multidomain and Multilayer Deployments 


Computing paths across large multidomain environments requires 
special computational components and cooperation between entities in 
different domains capable of complex path computation. The PCE 
provides an architecture and a set of functional components to 
address this problem space. A PCE may be used to compute end-to-end 
paths across multidomain environments using a per-domain path 
computation technique [RFC5152]. The Backward-Recursive PCE-based 
path computation (BRPC) mechanism [RFC5441] defines a PCE-based path 
computation procedure to compute interdomain-constrained MPLS and 
GMPLS TE networks. However, per-domain technique assumes that the 
sequence of domains to be crossed from source to destination is 
known, either fixed by the network operator or obtained by other 


means. BRPC can work best with a known domain sequence, and it will 
also work nicely with a small set of interconnected domains. 
However, it doesn’t work well for a large set of interconnected 
domains. 
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[RFC6805] describes a Hierarchical PCE (H-PCE) architecture that can 
be used for computing end-to-end paths for interdomain MPLS Traffic 
Engineering (TE) and GMPLS Label Switched Paths (LSPs) when the 
domain sequence is not known. Within the Hierarchical PCE (H-PCE) 
architecture, the Parent PCE (P-PCE) is used to compute a multidomain 
path based on the domain connectivity information. A Child PCE 
(C-PCE) may be responsible for a single domain or multiple domains; 
it is used to compute the intradomain path based on its domain 
topology information. 


[PCE-HPCE] states the considerations for stateful PCEs in 
Hierarchical PCE architecture. In particular, the behavior changes 
and adds to the existing stateful PCE mechanisms (including PCE- 
initiated LSP setup and active PCE usage) in the context of networks 
using the H-PCE architecture. 


[RFC5623] describes a framework for applying the PCE-based 
architecture to interlayer (G)MPLS TE. It provides suggestions for 
the deployment of PCE in support of multilayer networks. It also 
describes the relationship between PCE and a functional component in 
charge of the control and management of the Virtual Network Topology 
(VNT) [RFC5212] called the VNT Manager (VNTM). 


2.1.3. Relationship to PCE-Based Central Control 


[RFC8283] introduces the architecture for PCE as a central controller 
(PCECC); it further examines the motivations and applicability for 
PCEP as a southbound interface (SBI) and introduces the implications 
for the protocol. Section 2.1.3 of [RFC8283] describes a hierarchy 
of PCE-based controllers as per the PCE Hierarchy Framework defined 
in [RFC6805]. 


2.2. Abstraction and Control of TE Networks (ACTN) 


[RFC8453] describes the high-level ACTIN requirements and the 
architecture model for ACTIN, including the entities Customer Network 
Controller (CNC), Multidomain Service Coordinator (MDSC), and 
Provisioning Network Controller (PNC) and their interfaces. 


The ACIN reference architecture is shown in Figure 1, which is 
reproduced here from [RFC8453] for convenience. [RFC8453] remains 
the definitive reference for the ACTN architecture. As depicted in 
Figure 1, the ACTIN architecture identifies a three-tier hierarchy. 
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SBI - (Southbound Interface) 


Figure 1: ACTN Hierarchy 
There are two interfaces with respect to the MDSC: one north of the 
MDSC (the CNC-MDSC Interface (CMI)), and one south (the MDSC-PNC 


Interface (MPI)). A hierarchy of MDSCs is possible with a recursive 
MPI interface. 


[RFC8454] provides an information model for ACTN interfaces. 
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3. 


Architectural Considerations 


The ACTN architecture [RFC8453] is based on the hierarchy and 
recursiveness of controllers. It defines three types of controllers 
(depending on the functionalities they implement). The main 
functionalities are: 

o Multidomain coordination 

o Abstraction 

o Customer mapping/translation 


o Virtual service coordination 


Section 3 of [RFC8453] describes these functions. 


It should be noted that this document lists all possible ways in 
which PCE could be used for each of the above functions, but all 
functions are not required to be implemented via PCE. Similarly, 
this document presents the ways in which PCEP could be used as the 
communications medium between functional components. Operators may 
choose to use the PCEP for multidomain coordination via stateful 
H-PCE but alternatively use Network Configuration Protocol (NETCONF) 
[RFC6241], RESTCONF [RFC8040], or BGP - Link State (BGP-LS) [RFC7752] 
to get access to the topology and support abstraction function. 


.1. Multidomain Coordination via Hierarchy 


With the definition of domain being everything that is under the 
control of the single logical controller, as per [RFC8453], it is 
needed both to have a control entity that oversees the specific 
aspects of the different domains and to build a single abstracted 
end-to-end network topology in order to coordinate end-to-end path 
computation and path/service provisioning. 


The MDSC in ACTIN framework realizes this function by coordinating the 
per-domain PNCs in a hierarchy of controllers. It also needs to 
detach from the underlying network technology and express customer 
concerns by business needs. 


[RFC6805] and [PCE-HPCE] describe a hierarchy of PCEs with the Parent 
PCE coordinating multidomain path computation function between Child 
PCEs. It is easy to see how these principles align, and thus how the 
stateful H-PCE architecture can be used to realize ACTN. 
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The per-domain stitched LSP in the Hierarchical stateful PCE 
architecture, described in Section 3.3.1 of [PCE-HPCE], is well 
suited for multidomain coordination function. This includes domain 
sequence selection, End-to-End (E2E) path computation, and 
controller-initiated (PCE-initiated) path setup and reporting. This 
is also applicable to multilayer coordination in case of IP+toptical 
networks. 


[PCE-STATE-SYNC] describes the procedures to allow a stateful 
communication between PCEs for various use cases. The procedures and 
extensions are also applicable to Child and Parent PCE communication 
and are thus useful for ACTN as well. 


3.2. Abstraction 


To realize ACTIN, an abstracted view of the underlying network 
resources needs to be built. This includes global network-wide 
abstracted topology based on the underlying network resources of each 
domain. This also includes abstract topology created as per the 
customer service connectivity requests and represented as a VN slice 
allocated to each customer. 


In order to compute and provide optimal paths, PCEs require an 
accurate and timely Traffic Engineering Database (TED). 
Traditionally, this TED has been obtained from a link-state (LS) 


routing protocol supporting traffic engineering extensions. PCE may 
construct its TED by participating in the IGP ([RFC3630] and 
RFC5305] for MPLS-TE; [RFC4203] and [RFC5307] for GMPLS). An 


alternative is offered by BGP-LS [RFC7752]. 


In case of H-PCE [RFC6805], the Parent PCE needs to build the domain 
topology map of the child domains and their interconnectivity. 
RFC6805] and [PCE-INTER-AREA] suggest that BGP-LS could be used as a 
"northbound" TE advertisement from the Child PCE to the Parent PCE. 


PCEP-LS] proposes another approach for learning and maintaining the 
Link-State and TE information as an alternative to IGPs and BGP 
flooding, using PCEP itself. The Child PCE can use this mechanism to 
transport Link-State and TE information from Child PCE to a Parent 
PCE using PCEP. 


In ACTN, there is a need to control the level of abstraction based on 
the deployment scenario and business relationship between the 
controllers. The mechanism used to disseminate information from the 
PNC (Child PCE) to the MDSC (Parent PCE) should support abstraction. 
[RFC8453] describes a few alternative approaches of abstraction. The 
resulting abstracted topology can be encoded using the PCEP-LS 
mechanisms [PCEP-LS] and its optical network extension 
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[PCEP-OPTICAL]. PCEP-LS is an attractive option when the operator 
would wish to have a single control-plane protocol (PCEP) to achieve 
ACTN functions. 


[RFC8453] discusses two ways to build abstract topology from an MDSC 
standpoint with interaction with PNCs. The primary method is called 
automatic generation of abstract topology by configuration. With 
this method, automatic generation is based on the abstraction/ 
summarization of the whole domain by the PNC and its advertisement on 
the MPI. The secondary method is called on-demand generation of 
supplementary topology via Path Compute Request/Reply. This method 
may be needed to obtain further complementary information such as 
potential connectivity from Child PCEs in order to facilitate an end- 
to-end path provisioning. PCEP is well suited to support both 
methods. 


3.3. Customer Mapping 


In ACTN, there is a need to map customer virtual network (VN) 
requirements into a network provisioning request to the PNC. That 
is, the customer requests/commands are mapped by the MDSC into 
network provisioning requests that can be sent to the PNC. 
Specifically, the MDSC provides mapping and translation of a 
customer’s service request into a set of parameters that are specific 
to a network type and technology such that the network configuration 
process is made possible. 


[RFC8281] describes the setup, maintenance, and teardown of PCE- 
initiated LSPs under the stateful PCE model, without the need for 
local configuration on the PCC, thus allowing for a dynamic network 
that is centrally controlled and deployed. To instantiate or delete 
an LSP, the PCE sends the Path Computation LSP Initiate Request 
(PCInitiate) message to the PCC. As described in [PCE-HPCE], for 
interdomain LSP in Hierarchical PCE architecture, the initiation 
operations can be carried out at the Parent PCE. In this case, after 
Parent PCE finishes the E2E path computation, it can send the 
PCInitiate message to the Child PCE; the Child PCE further propagates 
the initiate request to the Label Switching Router (LSR). The 
customer request is received by the MDSC (Parent PCE), and, based on 
the business logic, global abstracted topology, network conditions, 
and local policy, the MDSC (Parent PCE) translates this into a per- 
domain LSP initiation request that a PNC (Child PCE) can understand 
and act on. This can be done via the PCInitiate message. 


PCEP extensions for associating opaque policy between PCEP peer 
[ASSOC-POLICY] can be used. 
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3.4. Virtual Service Coordination 


Virtual service coordination function in ACTN incorporates customer 
service-related information into the virtual network service 
operations in order to seamlessly operate virtual networks while 
meeting customers’ service requirements. 


[PCEP-VN] describes the need for associating a set of LSPs with a VN 
"construct" to facilitate VN operations in PCE architecture. This 
association allows the PCEs to identify which LSPs belong to a 
certain VN. 


This association based on VN is useful for various optimizations at 
the VN level, which can be applied to all the LSPs that are part of 
the VN slice. During path computation, the impact of a path for an 
LSP is compared against the paths of other LSPs in the VN. This is 
to ensure optimization and SLA attainment for the VN rather than for 
a single LSP. Similarly, during reoptimization, advanced path 
computation algorithms and optimization techniques can be considered 
for all the LSPs belonging to a VN/customer and optimize them all 
together. 


4. Interface Considerations 


As per [RFC8453], to allow virtualization and multidomain 
coordination, the network has to provide open, programmable 
interfaces in which customer applications can create, replace, and 
modify virtual network resources and services in an interactive, 
flexible, and dynamic fashion while having no impact on other 
customers. The two ACTN interfaces are as follows: 


o The CNC-MDSC Interface (CMI) is an interface between a Customer 


Network Controller and a Multidomain Service Coordinator. It 
requests the creation of the network resources, topology, or 
services for the applications. The MDSC may also report potential 


network topology availability if queried for current capability 
from the Customer Network Controller. 


o The MDSC-PNC Interface (MPI) is an interface between a Multidomain 
Service Coordinator and a Provisioning Network Controller. It 
communicates the creation request, if required, of new 
connectivity of bandwidth changes in the physical network via the 
PNC. In multidomain environments, the MDSC needs to establish 
multiple MPIs, one for each PNC, as there are multiple PNCs 
responsible for its domain control. 
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In the case of a hierarchy of MDSCs, the MPI is applied recursively. 
From an abstraction point of view, the top-level MDSC, which 
interfaces the CNC, operates on a higher level of abstraction (i.e., 
less granular level) than the lower-level MDSCs. 


PCEP is especially suitable on the MPI as it meets the requirement 
and the functions as set out in the ACTN framework [RFC8453]. Its 
recursive nature is well suited via the multilevel hierarchy of PCE. 
PCEP can also be applied to the CMI as the CNC can be a path 
computation client while the MDSC can be a path computation server. 
Section 5 describes how PCE and PCEP could help realize ACTN on the 
MPI. 


5. Realizing ACTN with PCE (and PCEP) 


As per the example in Figure 2, there are 4 domains, each with their 
own PNC and MDSC on top. The PNC and MDSC need PCE as an important 
function. The PNC (or Child PCE) already uses PCEP to communicate to 
the network device. It can utilize the PCEP as the MPI to 
communicate between controllers too. 
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\ / 
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B31 B34 
| DOMAIN 3 B| 
4+--------------- + 


MDSC -> Parent PCE 
PNC -> Child PCE 
MPI -> PCEP 


Figure 2: ACTIN with PCE 


o Building Domain Topology at MDSC: PNC (or Child PCE) needs to have 
the TED to compute the path in its domain. As described in 
Section 3.2, it can learn the topology via IGP or BGP-LS. PCEP-LS 
is also a proposed mechanism to carry link state and traffic 
engineering information within PCEP. A mechanism to carry 
abstracted topology while hiding technology-specific information 
between PNC and MDSC is described in [PCEP-LS]. At the end of 
this step, the MDSC (or Parent PCE) has the abstracted topology 
from each of its PNCs (or Child PCE). This could be as simple as 
a domain topology map as described in [RFC6805], or it can have 
full topology information of all domains. The latter is not 
scalable, and thus, an abstracted topology of each domain 
interconnected by interdomain links is the most common case. 
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Dhody, 


* Topology Change: When the PNC learns of any topology change, 
the PNC needs to decide if the change needs to be notified to 
the MDSC. This is dependent on the level of abstraction 
between the MDSC and the PNC. 


VN Instantiate: When an MDSC is requested to instantiate a VN, the 
minimal information that is required would be a VN identifier and 
a set of end points. Various path computation, setup constraints, 
and objective functions may also be provided. In PCE terms, a VN 
Instantiate can be considered as a set of paths belonging to the 
same VN. As described in Section 3.4 and [PCEP-VN], the VN 
association can help in identifying the set of paths that belong 
to a VN. The rest of the information, like the endpoints, 
constraints, and objective function (OF), is already defined in 
PCEP in terms of a single path. 


* Path Computation: As per the example in Figure 2, the VN 

instantiate requires two end-to-end paths between (A in Domain 
1 to B in Domain 3) and (A in Domain 1 to C in Domain 4). The 
MDSC (or Parent PCE) triggers the end-to-end path computation 
for these two paths. MDSC can do path computation based on the 
abstracted domain topology that it already has, or it may use 
the H-PCE procedures (Section 3.1) using the PCReq and PCRep 
messages to get the end-to-end path with the help of the Child 
PCEs (PNC). Either way, the resultant E2E paths may be broken 
into per-domain paths. 


* A-B: (A-B13,B13-B31,B31-B) 
* A-C: (A-B13,B13-B31,B31-B34,B34-B43, B43-C) 


*  Per-Domain Path Instantiation: Based on the above path 
computation, MDSC can issue the path instantiation request to 
each PNC via PCInitiate message (see [PCE-HPCE] and [PCEP-VN]). 
A suitable stitching mechanism would be used to stitch these 
per-domain LSPs. One such mechanism is described in 
[PCE-INTERDOMAIN], where PCEP is extended to support stitching 
in stateful H-PCE context. 


* Per-Domain Path Report: Each PNC should report the status of 
the per-domain LSP to the MDSC via PCRpt message, as per the 
hierarchy of stateful PCEs ([PCE-HPCE]). The status of the 
end-to-end LSP (A-B and A-C) is made up when all the per-domain 
LSPs are reported up by the PNCs. 


* Delegation: It is suggested that the per-domain LSPs are 
delegated to respective PNCs so that they can control the path 
and attributes based on the conditions of each domain network. 
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* State Synchronization: The state needs to be synchronized 
between the Parent PCE and Child PCE. The mechanism described 
in [PCE-STATE-SYNC] can be used. 


o VN Modify: MDSC is requested to modify a VN, for example, the 
bandwidth for VN is increased. This may trigger path computation 
at MDSC as described in the previous step and can trigger an 
update to an existing per-intradomain path (via PCUpd message) or 
the creation (or deletion) of a per-domain path (via PCInitiate 
message). As described in [PCE-HPCE], this should be done in 
make-before-break fashion. 


o VN Delete: MDSC is requested to delete a VN, in this case, based 
on the E2E paths, and the resulting per-domain paths need to be 
removed (via PCInitiate message). 


o VN Update (based on network changes): Any change in the per-domain 
LSP is reported to the MDSC (via PCRpt message) as per [PCE-HPCE]. 
This may result in changes in the E2E path or VN status. This may 
also trigger a reoptimization leading to a new per-domain path, an 
update to an existing path, or the deletion of the path. 


o VN Protection: The VN protection/restoration requirements need to 
be applied to each E2E path as well as each per-domain path. The 
MDSC needs to play a crucial role in coordinating the right 
protection/restoration policy across each PNC. The existing 
protection/restoration mechanism of PCEP can be applied on each 
path. 


o In case a PNC generates an abstract topology towards the MDSC, the 
PCInitiate/PCUpd messages from the MDSC to a PNC will contain a 
path with abstract nodes and links. A PNC would need to take that 
as an input for path computation to get a path with physical nodes 
and links. Similarly, a PNC would convert the path received from 
the device (with physical nodes and links) into an abstract path 
(based on the abstract topology generated before with abstract 
nodes and links) and report it to the MDSC. 


6. IANA Considerations 


This document has no IANA actions. 
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7. 


Security Considerations 


Various security considerations for PCEP are described in [RFC5440] 
and [RFC8253]. Security considerations as stated in Sections 10.1, 
10.6, and 10.7 of [RFC5440] continue to apply on PCEP when used as an 
ACTN interface. Further, this document lists various extensions of 
PCEP that are applicable; each of them specify various security 
considerations that continue to apply here. 


The ACTIN framework described in [RFC8453] defines key components and 
interfaces for managed traffic-engineered networks. It also lists 
various security considerations such as request and control of 
resources, confidentially of the information, and availability of 
function, which should be taken into consideration. 


As per [RFC8453], securing the request and control of resources, 
confidentiality of the information, and availability of function 
should all be critical security considerations when deploying and 
operating ACTIN platforms. From a security and reliability 
perspective, ACTN may encounter many risks such as malicious attack 
and rogue elements attempting to connect to various ACTIN components 
(with PCE being one of them). Furthermore, some ACTIN components 
represent a single point of failure and threat vector, and must also 
manage policy conflicts and eavesdropping of communication between 
different ACIN components. [RFC8453] further states that all 
protocols used to realize the ACTIN framework should have rich 
security features, and customer, application, and network data should 
be stored in encrypted data stores. When PCEP is used as an ACTIN 
interface, the security of PCEP provided by Transport Layer Security 


(TLS) [RFC8253], as per the recommendations and best current 
practices in [RFC7525] (unless explicitly set aside in [RFC8253]), is 
used. 


As per [RFC8453], regarding the MPI, a PKI-based mechanism is 
suggested, such as building a TLS or HTTPS connection between the 
MDSC and PNCs, to ensure trust between the physical network layer 
control components and the MDSC. Which MDSC the PNC exports topology 
information to, and the level of detail (full or abstracted), should 
also be authenticated, and specific access restrictions and topology 
views should be configurable and/or policy based. When PCEP is used 
in MPI, the security functions, as per [RFC8253], are used to fulfill 
these requirements. 


As per [RFC8453], regarding the CMI, suitable authentication and 
authorization of each CNC connecting to the MDSC will be required. 

If PCEP is used in CMI, the security functions, as per [RFC8253], can 
be used to support peer authentication, message encryption, and 
integrity checks. 
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Appendix A. Additional Information 


In the paper [EXP], the application of the ACTN architecture is 
presented to demonstrate the control of a multidomain flexi-grid 
optical network by proposing, adopting, and extending: 


o the Hierarchical active stateful PCE architectures and protocols 


o the PCEP protocol to support efficient and incremental link-state 
topological reporting, known as PCEP-LS 


o the per-link partitioning of the optical spectrum based on 
variable-sized allocated frequency slots enabling network sharing 
and virtualization 


o the use of a model-based interface to dynamically request the 
instantiation of virtual networks for specific clients/tenants. 


The design and implementation of the test bed are reported in order 
to validate the approach. 
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